Date: Wed, 20 Apr 94 04:30:13 PDT From: Ham-Digital Mailing List and Newsgroup Errors-To: Ham-Digital-Errors@UCSD.Edu Reply-To: Ham-Digital@UCSD.Edu Precedence: Bulk Subject: Ham-Digital Digest V94 #123 To: Ham-Digital Ham-Digital Digest Wed, 20 Apr 94 Volume 94 : Issue 123 Today's Topics: **BYTE Magazine** features DSP, May 1994 Internet <-> packet gateway? Internet > Packet gateways?? Send Replies or notes for publication to: Send subscription requests to: Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the Ham-Digital Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Tue, 19 Apr 1994 14:38:24 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!vixen.cso.uiuc.edu!uchinews!kimbark!khopper@network.ucsd.edu Subject: **BYTE Magazine** features DSP, May 1994 To: ham-digital@ucsd.edu F.Y.I. ----- There are two excellent articles about DSP in the new May 1994 issue of BYTE Magazine. The first on pp22,23 carries the title "The Engines to Make Mul- timedia Mainstream". This two pager covers the Microsoft DSP API and a nice half-page on the TI TMS 32OC80. The article has a pie chart that indicates a trememdous growth (728$mill to 2,493$Mil) in DSP sales from 1993 to 1997. The second article is on pp 81-86 and has the title "Desktop Data Conferencing". There is an excellent chart showing various pic- ture formats and the corresponding required bandwidth for un- compressed and compressed transmission. DSP is highlighted as the solution to bringing Teleconferencing to our bandwidith limited telecommunication channels. Page 84 has a 2/3 page special inset on "DSP's and the PC Mainstream" that clarifies the DSP API and the AT&T VCOS, IBM MWAVE, and SPOX. The various "DSP Operating Systems" are displayed in a brief figure on the same page. Page 86 has a table depicting 15 different alforithms (CLEP...G.711...V.32...) and their bit stream speeds and DSP re- quirements. Good articles with more than introductory information. ___________ Ken Hopper, | ___ | November 9 Vivid Video |o o \_/ o o| HF - CW,PacTOR,RTTY,SSTV |o o @ o o| khopper@midway.uchicago.edu |___________| ------------------------------ Date: Tue, 19 Apr 1994 15:39:13 GMT From: ihnp4.ucsd.edu!pacbell.com!tandem!news@network.ucsd.edu Subject: Internet <-> packet gateway? To: ham-digital@ucsd.edu In article cjt@transfer.stratus.com, ansaldo@fstop.hw.stratus.com (Robert Ansaldo) writes: >I seem to remember seeing something here about an internet connected machine >that will forward email via packet radio. I tried looking back, but the >article(s) must have expired. N6QMY/BBS Internet Gateway Operating Instructions April 11, 1993 LOCAL USERS: ------------ Local users are those that log into the bbs via the bbs's telephone modem port (510-795-xxxx) or via one of the 4 tnc ports (145.09, 145.79, 223.62, or 441.50). Each local user has a bbs account that is used to customize how the bbs interacts with the user. Local users can set their account up so that all incoming mail addressed to their call will be forwarded via a gateway to internet and on to other networks (mcimail, compuserve, etc). All the user needs to do is enter his email address and turn the feature on. EMAIL bob@hal.com EMAIL ON When the EMAIL feature is turned on the packet message will be deleted at the time of forwarding through the gateway. So care should be taken that the paths are correct prior to turning the feature on, for instance enable it, send a test message, and disable it. After a successful transfer re-enable the feature. To disable the auto forwarding feature simply type: EMAIL OFF Messages can be sent by packet users to the internet users via the gateway. This applies to users at N6QMY as well as users at other bbs's. Begin by sending a message to IPGATE@N6QMY with the first line of the message being the letters "To:" followed by the internet address of the recipient. KB6UCZ de N6QMY > sp ipgate@n6qmy Enter your subject: Meeting? Enter your message body: To: bob@hal.com Are you planning to attend the club meeting on Thursday? Give me a call. 73, Theresa ^Z NOTE: That the recipient cannot respond to the message unless they are a ham and registered with the gateway. He/she becomes registered by sending a message from his internet host to gateway-request@lbc.com. REMOTE USERS: ------------- Remote users are those that do not log into N6QMY directly but merely appear from the packet world to use it as home. If a packet user checks the "White Pages" for a remote user the entry comes back as @N6QMY. The packet user then address his message to YOURCALL@N6QMY and the bbs will do the translation and forwarding to internet. It is not necessary for a person to know your actual internet address nor use the SP IPGATE method described above. From the packet network it appears that you are just another user at N6QMY. WHITE PAGES: ------------ The "White Pages" is a distributed database of all the bbs users. Most bbs users in the US are represented in the database as well as many from other countries. When a user chooses a home bbs, that bbs generates an update that is sent to the regional servers and then distributed to all the other bbs's. An entry consists of; call, home bbs, first name, zip, city and state. When a user wishes to send another packet user a message he/she consults the white pages (WP) for the home bbs. REGISTERING: ------------ Before a user, both local and remote, can send a message from internet into the bbs system he/she must register with the gateway. This is done by sending a message from the host that he/she intends to use to gateway-request@lbc.com with the following information: CALL: FIRST NAME: CITY & ST: ZIP: HOME BBS: When a request is received the "From" field is copied directly into a file with the requesters call. Whenever the gateway receives a message bound for packet it scans this file comparing on the "From" field. When a match is found the gateway uses the associated call from then on. If there is no match the mailer bounces the message with a one-liner indicating the the user must register. If you currently use another bbs as home this needs to be stated in the request. Otherwise you will be assigned N6QMY as your home. If you choose not to use N6QMY as your home you must make sure people know to send your message to YOURCALL@N6QMY to pass through the gate. Your WP entry will be wrong. EXECUTING BBS COMMANDS REMOTELY: -------------------------------- Many of the commands available to local users is also available to remote users by sending a message to the bbs. Here is a subset of the commands currently available. LIST listing messages LOOKUP look up calls in the on-line callbook WHO call dump a users account information READ read messages and files USERS n display the last n users to connect to the bbs INFO display manual pages of various topics CD change directories in the file system LS/DIR display the contents of a directory WP call look a user up in the "White Pages" HELP get help on how to use a command Not all commands available to local users can be accessed via the gate. All interactive commands are disabled as well as commands that modify the users account. The command parser for the bbs is very powerful and the user can form very complex requests. For instance the following command is valid on the bbs: LIST LAST 20 BULLETINS FROM N6QMY LIST ALL BULLETINS ABOUT KENWOOD The ABOUT keyword is used to search the subjects of messages for a given pattern, in this case KENWOOD. It can appear anywhere in the subject line. This is an example of how complex all the commands can become. They can also be abbreviated down to the level understood my most other bbs programs. Any of the following will give the same results. L< N6ZFJ LIST FROM N6ZFJ LIS < N6ZFJ L FR N6ZFJ In most cases a minimum number of unique characters is needed to distinguish a command. You can get a list of commands and a translation chart from the W0RLI BBS command set to the N0ARY BBS command set by typing the following commands: INFO COMMANDS INFO W0RLI Other commands that you may wish to execute are: INFO MANUAL HELP HELP HELP LIST Now that you know what some of the commands are this is how you go about executing them. You send a message to cmd@bbs.lbc.com with your commands entered one per line or separated by semicolons. For example if you want to know if three of your buddies are in the white pages and if the bbs has any messages about the ICOM W2A. Send to: cmd@bbs.lbc.com Subject: you can put anything here wp n0ary n6zfj n6une list all about w2a . The bbs will execute the commands and respond to you via return mail. SENDING MAIL TO PACKET: ----------------------- Once registered the user is free to begin using the gateway to send messages from his host through the gateway into the packet world. How much you have to specify of a users address depends on how much the bbs already knows about the user. If the bbs knows the home bbs of the user and his home bbs is know to the N6QMY bbs, which many of them are, you simply need to supply the call of the user. n6oim@bbs.lbc.com If the N6QMY bbs doesn't know of the user but does know where his home bbs is, then you need to supply just the home bbs call in addition to the users. n6oim%n6iiu@bbs.lbc.com Notice that the call and home bbs are separated by a percent sign '%' rather then the '@' which is used in the packet domain. This is because the '@' has a meaning in the internet address. If the N6QMY bbs has no knowledge of either the user or his home bbs, then you probably have the wrong home bbs or it is a new bbs. In which case you will have to supply the full address so the bbs will know how to route the message. n6oim%n6iiu.#nocal.ca.usa.na@bbs.lbc.com This level of addressing is hardly ever needed and normally means that the home bbs is in error. Bulletins can be sent in a similar fashion. The address is made up of a keyword, which can be any six character word and a distribution. Distributions are local to an area. For instance SBAY is valid in northern CA, it probably has no meaning at all in Topeka, KS. Valid distributions are: ALLUS please avoid this one ALLUSW all western US ALLCA all California, any 2 letter state should work So if you trying to find a cw filter for a Kenwood TS440. Send to: want%allca@bbs.lbc.com Subject: Kenwood TS440, CW filter If you have one of these you are willing to part with please give me a call or leave message, thanks. 73, KB6UCZ@N6QMY.#NOCAL.CA.USA.NA . Be descriptive, brief, and always include your full return address in the message. Also please try to limit your distributions to small regions. Using the ALLUS distribution really slows down the flow of messages. INFO ON THE N6QMY BBS: ---------------------- The bbs came into being in April of 1993 and was the second one anywhere to run the N0ARY BBS code (the first being N0ARY himself). The bbs has 4 rf ports, 1 phone port, the internet port, and is working on a voice synthesizer port. The latter would allow users to check for messages via DTMF from their handhelds. The bbs itself runs on a Sun workstation under Unix. The code was written by Bob Arasmith (N0ARY) to focus on the user. Great care was taken to make the bbs very forgiving to the novice user but very flexible and powerful for the old-timer. The bbs can be configured to interact with each user differently. Some examples are: * List messages in either descending or ascending order. * Specify a list of keywords that the user wishes not to see displayed when a list is performed, similar to a kill file. * .signature and .vacation files. * Specify how many lines the users terminal is capable of displaying before scrolling, the bbs will feed info this many lines and pause allowing the user to catch up and continue or abort the operation. Similar to more. * Users can put commonly executed commands in keystroke macros that are accessible via a single keystroke. A manual is currently available describing the commands and their permutations. This manual will be available later this year as a postscript file. Run the command INFO MANUAL to learn how to get one via the post office. It is not available in an ascii format. If you have any questions about the internet gateway or the bbs in general please drop me a message. 73, -pat n6qmy@n6qmy.#nocal.ca.usa.na pat@lbc.com ------------------------------ Date: 19 Apr 94 20:10:06 GMT From: agate!howland.reston.ans.net!europa.eng.gtefsd.com!library.ucla.edu!ihnp4.ucsd.edu!pacbell.com!amdahl!amd!netcomsv!telesoft!garym@ucbvax.berkeley.edu Subject: Internet > Packet gateways?? To: ham-digital@ucsd.edu In marcbg@netcom.com (Marc B. Grant) writes: >Does anyone have a list of Internet > Packet gateways? I use N0ARY, but >would like to find others closer to some other geographic locations. Here is the short list of I have. It's probably not complete and some of the older ones may no longer be operating. I haven't verified any of these except N0ARY which the one I use. Does anyone know of any we can add to the list? Especially any in Southern California? --GaryM Internet Email / Amateur Packet Gateways Location BBS Contact Address Date of Info -------------- ------- ----------------------- ------------ Sunnyvale, CA N0ARY gateway_info@arasmith.com 94-04 Fremont, CA N6QMY gateway_info@lbc.com 94-02 Arizona WB7TPY david@stat.com 93-05 New Jersey KA2QHD johnd@ka2qhd.ocpt.ccur.com 92-05 Pittsburg W2XO durham@w2xo.pgh.pa.us 92-05 ------------------------------ Date: Tue, 19 Apr 1994 15:51:02 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.intercon.com!panix!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!eff!blanket.mitre.org!world!dts@network.ucsd.edu To: ham-digital@ucsd.edu References <2oh1qh$q5n@hp-col.col.hp.com>, <2okn8t$c74@hpbab.mentorg.com>, <2om9kt$qtl@insosf1.infonet.net>ich.edu Subject : Re: NTS traffic on packet In article <2om9kt$qtl@insosf1.infonet.net> billh@ins.infonet.net writes: >In article <2okn8t$c74@hpbab.mentorg.com>, hanko@wv.mentorg.com (Hank Oredson) writes: >>In article <2oh1qh$q5n@hp-col.col.hp.com>, jms@col.hp.com (Mike Stansberry) writes: >>|> Hank Oredson (hanko@wv.mentorg.com) wrote: >>|> : In article <2oblv6$bme@hp-col.col.hp.com>, jms@col.hp.com (Mike Stansberry) writes: >>|> : |> Hank Oredson (hanko@wv.mentorg.com) wrote: >>|> : |> : In article , ostroy@cbnewsh.cb.att.com (Dan Ostroy ) writes: >>|> : |> >>|> : |> : The days of handling traffic on 80M CW are pretty much gone now, just >>|> : |> ^^^^^^ >>|> : |> **** WRONG!!! *** Just because YOU don't do it, don't assume it's >>|> : |> gone. I handle a LOT of traffic on 80M (and 40M) CW and so do a >>|> : |> lot of others! >>|> : |> >>|> : |> Mike, K0TER >>|> : |> >>|> >>|> : I'm certainly sorry to hear that. >>|> >>|> : Sounds terribly inefficient and error prone, when there are >>|> : better ways to do it. >>|> >>|> : -- >>|> >>|> : Hank Oredson @ Mentor Graphics >>|> : Internet : hank_oredson@mentorg.com >>|> : Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM >>|> >>|> I guess you are just not interested in trying to help. Use your >>|> system or none at all, right? End of discussion. >> >>*** Flame mode on: >> >>So what should I do to try and help? Spell it out and stop whining. >> >>I guess differently than you do: I am trying to help by working to create >>a network that will gaurantee error free movement of messages >>anyplace in the world. >> >>Did I say "none at all"? No I did not. >>Please pay attention and read what was written (it's right up there ..). >>I said that 80M CW sounds terribly inefficient and error prone. >> >>Your response is what I hear from the majority of hams presently involved >>in NTS: "Oh my, Oh my, Run Away! - the Computers are coming, and we are >>afraid they will replace us!" >> >>In what way would you like me to help? By getting on 80M CW? >>No thanks, I've done that, and know perfectly well that it is error >>prone, slow, and can handle only a tiny amount of traffic. >> >>What I have been saying is that NTS fails to make use of all >>resources available to it, and in particular appears to be stuck in >>the dark ages of message handling. >> >>"End of discussion" sounds a lot like "I refuse to hear what you have >>to say, and will continue to refuse to hear it." >> >>*** Flame mode off: >> >> >>Indeed, not all NTS participants are like Mike. >> >>Some appear to understand what *could* be done, and would like to move >>NTS forward. However from my experience they are in the minority, and >>the "Mikes of the world" are in the majority. >> >> ... Hank >> >>-- >> >>Speaking only for myself (but you knew that, didn't you) >> >>Hank Oredson @ Mentor Graphics >>Internet : hank_oredson@mentorg.com >>Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM >If CW/VOICE is so efficient, why does NTS highly suggest that msgs be limited >to 20 or 25 words or less. Compare that to length of many msgs/bulls on pkt. >bill Hays, W0OMV I guess you don't deliver much traffic. Some of us who do, prefer not to spend our whole lives at it. Remeber that there IS a human doing the delivery at the other end, and that NTS traffic is often send by and received by NON-hams. -- --------------------------------------------------------------- Daniel Senie Internet: dts@world.std.com Daniel Senie Consulting n1jeb@world.std.com 508-779-0439 Compuserve: 74176,1347 ------------------------------ Date: Tue, 19 Apr 1994 15:57:38 GMT From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!news.intercon.com!panix!zip.eecs.umich.edu!yeshua.marcam.com!news.kei.com!eff!blanket.mitre.org!world!dts@network.ucsd.edu To: ham-digital@ucsd.edu References <2okn8t$c74@hpbab.mentorg.com>, <2om1ki$pkb@hp-col.col.hp.com>, <2oujlo$36a@hpbab.mentorg.com>um Subject : Re: NTS traffic on packet In article <2oujlo$36a@hpbab.mentorg.com> Hank_Oredson@mentorg.com writes: >In article <2om1ki$pkb@hp-col.col.hp.com>, jms@col.hp.com (Mike Stansberry) writes: > >|> Tell me what needs to be done to stop doubling, tripling, or even more >|> of messages. Tell me what needs to be done to get the time in transit >|> of messages sent via packet down from 5 to 10 days to something >|> reasonable. Don't tell me the above statements are not true. I'm >|> keeping track of the header information on the messages I deliver >|> that travelled by packet and the 5 to 10 days is the norm/. > >Ok, I'll tell you what to do to solve these problems. > >This is what we do in our part of the network whenever problems such >as you describe occur. Once located, the problem is usually quickly fixed. > >With respect to these 5-10 day delays you claim to see: > >1. Track the messages to find out where the delays occur. >2. Send this information to SYSOP@USA (or to the appropriate sysops > directly) so everyone involved knows where the problems occur, > and can work to fix them. >3. Create better routings so the delays do not occur. These are all excellent suggestions. The problem is, the folks who handle NTS traffic are not necessarily interested in the WAY that the tool (packet) works, just that it does work. I don't see anything wrong with that approach to packet at all. I, for one, do network stuff for a living, and like to do something OTHER than debugging networks when I get home. Perhaps the packet network systems should have some sort of routine test messages that get spread over the various paths and analyzed? There is no real reason to rely on end users to report problems of this sort. > >If the above is not clear, then simply post a few messages to SYSOP @ USA >including the headers from these delayed messages. We can't fix anything >until we know where the problem occurs. You have not given us that >information yet. > >With respect to the duplicates you claim to see: > >1. Track the messages to find out where the duplicates occur. >2. Send this information to SYSOP@USA (or to the appropriate sysops > directly) so everyone involved knows where the problems occur, > and can work to fix them. >3. Adjust your forwarding or connect parameters so the duplicates > no longer occur. > >If the above is not clear, then simply post a few messages to SYSOP @ USA >including the headers from these duplicated messages. We can't fix anything >until we know where the problem occurs. You have not given us that >information. > >The above is simply common sense: it is how we manage the network so it >will meet reasonable requirements on delay times, etc. > >Do we see delays and duplicates like this in the Pacific NW? >Yes, of course we do. >Do we allow them to continue? >No, we do not. >We manage the network to locate and repair problems like this. >They are usually simple problems that yield to simple solutions. Now if the network were as well managed everywhere, we'd be all set. It takes people who WANT to spend their ham radio time doing this. I'm sure there are such people all over, but they are not necessarily the ones handling NTS traffic. > > ... Hank > >-- > >Hank Oredson @ Mentor Graphics >Internet : hank_oredson@mentorg.com >Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM -- --------------------------------------------------------------- Daniel Senie Internet: dts@world.std.com Daniel Senie Consulting n1jeb@world.std.com 508-779-0439 Compuserve: 74176,1347 ------------------------------ End of Ham-Digital Digest V94 #123 ******************************